home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 526 < prev    next >
Internet Message Format  |  1996-08-06  |  3KB
  1. Path: tbj.dec.com!diamond
  2. From: diamond@tbj.dec.com (Norman Diamond)
  3. Newsgroups: comp.std.c
  4. Subject: Re: Bit-field sizes
  5. Date: 8 Mar 1996 03:04:38 GMT
  6. Organization: Digital Equipment Corporation Japan , Tokyo
  7. Message-ID: <4ho846$g2d@usenet.pa.dec.com>
  8. References: <nzRPxQ9ytZZA084yn@csn.net> <4hkgds$bbh@info1.sdrc.com> <uYgPxQ9ytt9W084yn@csn.net> <4hn3mg$c9v@info1.sdrc.com>
  9. Reply-To: diamond@tbj.dec.com (Norman Diamond)
  10. NNTP-Posting-Host: jit533.tbj.dec.com
  11.  
  12. In article <4hn3mg$c9v@info1.sdrc.com>, larry.jones@sdrc.com (Larry Jones) writes:
  13. # (quoting the standard):
  14. # The expression that specifies the width of a bit-field shall be
  15. # an integral constant expression that nas nonnegative value that
  16. # shall not exceed the number of bits in an ordinary object of
  17. # compatible type.
  18. #
  19. >In article <uYgPxQ9ytt9W084yn@csn.net>, thads@csn.net (Thad Smith) writes:
  20. >> What does "ordinary object of compatible type" mean?  Could that mean
  21. >> long?  I now think that an implementation could allow specification of
  22. >> a number of bits greater than int, but less than or equal to bits in
  23. >> long.  To access the value, the programmer casts the bit-field to long
  24. >> or unsigned long.  The cast would preceed the integral promotion, I
  25. >> think, and allow access to the longer value.
  26.  
  27. >An ordinary object (i.e., not a bit-field) with the same type as the
  28. >declared type of the bit-field which is required to be int, signed int,
  29. >or unsigned int.  As Norm Diamond pointed out, that requirement is in
  30. >semantics, not constraints, so an implementation is free to add an
  31. >extension allowing other types (like long), and some do.
  32.  
  33. Although I'm missing half the postings in this thread, everything sounds
  34. right so far.
  35.  
  36. >Such implementations presumably extend the integral promotion rules in
  37. >the obvious fashion as well in order to eliminate the need for casts.
  38.  
  39. They cannot.  As Thad Smith's original posting pointed out, the standard
  40. prohibits this extension.  And as Mr. Smith's later posting points out,
  41. as quoted above, a cast could do it.  In order to permit implementations
  42. to provide this further extension without requiring casts, it would be
  43. necessary to revise the wording in ANSI Classic section 3.2.1.1, page 35
  44. lines 12 to 15.  These lines (originally quoted my Mr. Smith) currently
  45. force the bit-field value into an int or unsigned int regardless.
  46. --
  47.  <<  If this were the company's opinion, I would not be allowed to post it.  >>
  48. "I paid money for this car, I pay taxes for vehicle registration and a driver's
  49. license, so I can drive in any lane I want, and no innocent victim gets to call
  50. the cops just 'cause the lane's not goin' the same direction as me" - J Spammer
  51.